The Atomic Manifesto: a Story in Four Quarks

This report summarizes the viewpoints and insights gathered in the Dagstuhl Seminar on Atomicity in System Design and Execution, which was attended by 32 people from four different scientific communities: database and transaction processing systems, fault tolerance and dependable systems, formal methods for system design and correctness reasoning, and hardware architecture and programming languages. Each community presents its position in interpreting the notion of atomicity and the existing state of the art, and each community identifies scientific challenges that should be addressed in future work. In addition, the report discusses common themes across communities and strategic research problems that require multiple communities to team up for a viable solution. The general theme of how to specify, implement, compose, and reason about extended and relaxed notions of atomicity is viewed as a key piece in coping with the pressing issue of building and maintaining highly dependable systems that comprise many components with complex interaction patterns

Transactional Memory and the Birthday Paradox

Transactional Memory (TM) has been proposed as an alternative implementation of mutual exclusion that avoids many of the drawbacks of locks (e.g., deadlock, reliance on the programmer to associate shared data with locks, priority inversion, and failures of threads while holding locks). TM enables the program- mer to denote atomic regions (transactions) that are executed optimistically; if a conflict is detected, the thread is rolled back to the beginning of the transaction. A Software Transactional Memory (STM) im- plements speculative execution (so that a roll back can be performed) and conflict detection by adding additional code to the application. In an STM that tracks mutual exclusion at a word or cache-line granularity, an ownership table is used to keep track of which transactions currently have read and write permissions to which regions of memory. Memory addresses are mapped to ownership table entries by hashing the memory address. A frequently proposed design for ownership tables (used in previous STM and hybrid hardware/software TM proposals) is that of a tagless table, where read and write permissions are granted at the granularity of all addresses that map to a given ownership table entry. When two transactions have memory accesses that map to the same ownership table entry, the tagless nature of this organization requires the STM to conservatively force one transaction to abort if one or more of the aliasing accesses is a write. Using address traces from a multithreaded program, we demonstrate that the frequency of these false conflicts grows superlinearly with both the TM data footprint and concurrency and that increasing the size of the ownership table results in only a sub-linear reduction in conflict rate. These somewhat surprising relationships have a theoretical foundation that is also responsible for the (naively) unintuitive statistical result generally referred to as the .Birthday Paradox.: that in a collection of at least 23 randomly chosen people, the probability is more than 50% that at least two of them will have the same birthday. In layman.s terms, two addresses are likely to map to the ownership table entry long before the table is full. We present an analytical model based on random population of an ownership table by concurrently executing transactions that correctly predicts the trends in measured data. From this study, we conclude that tagless ownership tables are not a robust approach to supporting transactional memories. Even large tables (. 64K entries) are only somewhat effective at mitigating false conflicts in the presence of modest sized transactions (e.g., 20 cache blocks) and modest degrees of concurrency (e.g., 4 simultaneous transactions). In contrast, tagged ownership tables, which record addresses and use chaining to handle aliasing, do not result in false conflicts and, when appropriately sized, only infrequently require chaining. This result is particularly important in the context of hybrid TMs, where the small transactions are likely handled in hardware, leaving only the large ones for the STM